NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/15888

Internet Message Format | 1996-08-05 | 3.9 KB

Path: news.nask.org.pl!usenet
From: [e-mail] (Piotr Parlewicz)
Newsgroups: comp.lang.c++
Subject: Re: 64K segment limit:Newbie seeks enlightenment
Date: Mon, 08 Apr 1996 18:19:21 GMT
Organization: Research and Academic Computer Network
Message-ID: <4kbl3g$[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: s111.maloka.waw.pl
X-Newsreader: Forte Free Agent 1.0.82

David McClure <[e-mail]> wrote:

>We're coding a computer sim in BC4.52 of human anatomy for and are
>concerned about the 64K segment limit with 3D arrays
>that are upto several megabytes in size.

>Could anyone expound on the 64K segment limit in win3.1. My limited
>understanding of it is 64K = segment length = local heap size+ stack heap +
>static data + 16 byte header.  Is this why arrays are limited to < 64K?
>We want to use upto 4 or 8 meg total 3D arrays (they simulate human anatomy).
>Right now we use triple pointers.  But how is this large array data
>accessed when the limit is 64K ? Also what is the limit for win3.51?
>I don't think we can use the huge memory model because that's only for
>DOS apps.


>*****************************
>*  [e-mail]  *
>*****************************


Hi David,
 here are some pointers I thought you could use that I learned
while programming for large arrays in BC++3.1. All the following
is true only for Windows 3.1 (16-bit protected mode).

I DONT know if this is true in native Windows NT (3.51).
However since all 16-bit applications should run in NT and Win95
then I guess it should work when used in a 16-bit app.

When coding for NT, you should have no problems with large memory,
since its supposed to be a true 32 bit system.

1. You can use huge pointers in the large model under Windows 3.1
The mechanism used by Windows in GlobalAlloc for large blocks of
memory gives you 'tiled selectors'.
The code generated for huge pointer arithmetic (+,-) handles the
tiled selectors correctly.
A 32 bit pointer in protected mode is made up of the selector (upper
16) bits and the offset (lower 16 bits)

A selector is a 16-bit id that maps into a table used by the CPU
to calculate effective addresses.

There can be a maximum of around 8000 unique selectors.
Underneath the 64KB selector-segments is linear memory space.
When allocating more than 64KB of memory, Windows internally allocates
consecutive selectors for each block of 64KB making up the requested
big block in linear memory space.
Unfortunately consecutive in this context means sel(n) = sel(n-1) + 8
(huge pointer arithmetic handles this correctly)

However this is not all there is to it!
When you have a pointer to a struct that straddles a segment boundary,
(and this will be possible whenever your struct size is not a multiple
of 2) and you try to refference a field in it that is after the
segment boundary, the code generated to access the structs fields will

loop around and you will get incorrect values.

To get around this problem I suggest one of the following:

a) allways use padded structs to make sure their sizeof is a multiple
of 2

b) Access the fields using your own little address fixer function
that will do some hanky panky on the pointer. (This require a bit more
explaining so if you want more on this e-mail me.)


2. Windows toolhelp.dll delivers some functions for reading and
writing to GlobalAlloced memory.

3. Remember that hmemcpy, is not hmemmov. You should not use it when
the source and destionation memory blocks overlap.
If you want I can e-mail you my own implementation of hmemmov in C.

4. If you want to use C style 3-d arrays, I'm not sure how the huge
keyword will influence your access. (I've never had to solve that
problem.) Maybe you would be better of using a macro that converts the
3 coordinates into a single coordinate item offset in the big array.

I hope this is usefull to you.

Piotr Parlewicz

[e-mail]